The National Emergency Number Association (NENA) provides various recommended standards for “Enhanced 911” (“E911”) services such as the “Interim VoIP Architecture for Enhanced 9-1-1 Services (i2),” Issue 1, December 2005. The purpose of this and other standards is to prepare the telecommunications industry for the use of Voice over Internet Technology (VoIP) as the predominant telephony technology, and to provide an interim architecture such that callers in an Internet Protocol (IP) domain may connect and be supported by Public Safety Answering Points (PSAPs) within the existing E911 network.
An example emergency services network architecture 100 for providing interconnection between an IP domain and existing E911 infrastructure, as recommended by NENA in the publication “Interim VoIP Architecture for Enhanced 9-1-1 Services (i2),” 08-001, Issue 1 (Dec. 6, 2005), is illustrated in FIG. 1. The left side of the architecture represents the IP domain which includes various private and public server providers. Call control interfaces in the IP domain may be Session Initiation Protocol (SIP), H.323, or some other suitable protocol that can provide the required NENA and call control functionality. The various interfaces are defined by NENA. The various dashed line interfaces “v1,” “v4,” “v5,” and “v6” represent logical signaling interfaces, such as SIP signaling interfaces. The solid line interfaces “v0,” “v2,” “v3,” “v7,” “v8,” and “v9” represent logical interfaces for exchanging location related data in the IP domain.
The Public Switched Telephone Network (PSTN) 101 in the circuit switched domain interfaces directly with the PSAP 131 as shown. On the circuit switched side, an Automatic Location Identification (ALI) database 133 provides the PSAP with a caller's address or geodetic (XY) location of the telephone and also supplementary emergency service information related to the location of call origination. Non-emergency calls can be sent between the PSTN 101 and the IP domain via a PSTN gateway 103 which interfaces with one or more routing proxy 105 and corresponding redirect servers 107.
To provide emergency service access for the IP domain, E911 selective routers 127 operate in conjunction with a Selective Routing Database (SRDB) 129 which is the routing table relating telephone numbers to Emergency Service Numbers (ESNs) and which determines the routing of 911 calls. The E911 selective routers interface with one or more Emergency Services Gateways (ESGW) 109 which provide a signaling and media interface between the circuit switched conventional E911 SRDB 129 and the IP domain.
In the IP domain dashed line, logical signaling interfaces, the v4 interface is for forwarding calls via the routing proxy 105, or call server/proxy 111, to the correct ESGW 109. The v5 interface is defined as a SIP interface between the call server/proxy 111 and redirect server(s) 107; while the v6 interface is defined as a SIP interface between the call server/proxy 111 and the routing proxy 105. A VoIP end point 115, such as a VoIP telephone, communicates with the call server/proxy 111 via the v1 interface.
In the IP domain, the solid line logical interfaces “v0,” “v2,” “v3,” “v7,” “v8,” and “v9” are related to location information. The VoIP end point 115 may receive pre-determined location information from a Location Information Server (LIS) 117 over the v0 interface. The LIS 117 may serve as a location information repository with either geo-spatial location data or civic address data, correlated to physical locations. The LIS 117 may also include a “wiremap,” that is, mappings between individual location information and logical representations of the physical locations. The VoIP Positioning Center (VPC) 113 provides routing information for VoIP emergency calls and helps deliver location information to the PSAP 131using the ALI 133 infrastructure using the v-E2 interface. The call server/proxy 111 uses the v2 interface to request emergency call routing information from the VPC 113 in architectures where the call server/proxy 111 and/or the routing proxy 105 and redirect server(s) 107 are separate elements from the VPC 113.
The v3 interface is defined as an optional interface that allows the VPC 113 to obtain an emergency caller's location from the LIS 117. The v7 interface is a location validation interface between the LIS 117 and the Validation Database (VDB) 135, that the LIS 117 uses to request validation of a specific civic location. The VDB 135 checks the civic location, received in the request, in the Standard Master Street Address Guide (MSAG) 125. A database management system (DBMS) 123 interacts with the MSAG 125, the VDB 135 and an Emergency Services Zone Routing Database (ERDB) 119. The VPC 113 may query the ERDB 119 using the v8 interface and obtain routing information and other information for an emergency caller. The v9 interface enables the LIS 117 or the VPC 113 to discover the appropriate VDB/ERDB via the Root Discovery Server 121.
FIG. 2 illustrates an example of an existing software architecture 200 for obtaining location information from a mobile device GPS location system supporting both E911 Phase 2 calls requiring precise location, and Location-based services (LBS). The software architecture 200 illustrates a portion of a software stack that includes an application layer having various third party applications 203. An operating system location provider 205, provides location information to the third party applications 203 based on restrictions related to a user location privacy setting 201 which, in turn, pertains to LBS usage. The user privacy setting 201 may be, for example, stored in a memory location of the mobile device. The operating system location provider 205 may receive location information requests from any of the various third party applications 203. In response, the operating system location provider 205 will check the user privacy setting 201 and, in compliance with the setting, will obtain location information from, for example, GPS chip 209 via a hardware abstraction layer 207. If the user privacy setting is, for example, set to “GPS Disabled,” then an LBS application needing the user's GPS location would receive an error message when attempting to obtain the location. The location information could also be obtained from location servers which may utilize measurements provided by GPS chip 209. For emergency call purposes, a trusted or embedded 911 dialer 211 is present that directly accesses the GPS chip 209, and thus location information, via the hardware abstraction layer 207, regardless of the user privacy setting. This trusted dialer is now used mostly for circuit switched 911 access using a traditional circuit switched wireless technology for voice calls such as GSM, UMTS, and CDMA 1X, however it could also be used for “managed” VoIP services specified by the wireless operator for voice calling on an LTE network, for example. Some configurations of the software architecture 200 may also include an emergency-capable location provider 213 which operates for trusted uses only (such as operating in conjunction with trusted native or embedded 911 dialer 211).
Various problems exist for implementing “Next Generation” 911 (NG911) systems within the constraints of the network and mobile device architectures illustrated in FIG. 1 and FIG. 2. Specifically, given that the latest model mobile devices provide interfaces for access by various third party software developers, any so-called “over-the-top” VoIP applications, capable of dialing 911, could come from any third-party whose trustworthiness cannot be guaranteed. Although the FCC rules currently do not require such over-the-top VoIP applications to comply with E911 Phase 2 requirements, it is contemplated that the FCC may change its policy and allow any downloadable VoIP application to be able to dial 911, obtain Phase 2 location, and then deliver it to a P SAP. On one hand, the enforcement of the user privacy setting for NG911-compatible applications means that the emergency application may be refused access to the GPS hardware by the OS location provider, thus precluding one of the primary uses of the emergency application. On the other hand, the bypassing of the user privacy setting for NG911-compatible applications places private personal location information at risk.
For example, a third party NG911-compatible application may be able to access readable latitude and longitude information even though the user has turned on their mobile device location privacy setting. A malicious or defective VoIP or messaging application may leak the user's latitude and longitude to unwanted parties, against the explicit wishes of the user.